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MERCHANT TRANSACTION DATA MINING METHOD 

FIELD OF THE INVENTION 

The present invention relates to systems and 
methods for the analysis of large quantities of credit 
transactions and more particularly to a system and method 
for enabling the effective marketing of credit card 
services to existing customers. 

BACKGROUND OF THE INVENTION 

Issuers of debit and credit cards currently 
perform analysis ("data mining") of the transactions 
their customers conduct with respect to the card issued 
by the issuer. This transactional information is 
acquired directly by the issuer because of the use of the 
issuer's card by the customer. The transactional data 
can include information with respect to where the 
customer has used the card, how much has been spent on 
the card, the type of merchants frequently visited and 
which card services are most often used by the customer. 

A significant deficiency in the analysis 
currently performed by issuers is that the analysis is 
only performed with respect to transactions occurring on 
the issuer's own card or cards. In reality, consumers 
often have several credit and/or debit cards from several 
issuers. For example, some consumers use a particular 
credit card for travel because of incentives provided by 
the issuer of that card, while the same consumer uses a 
different card for other more general purposes. 



In the current systems and methods of analysis 
used by issuers, the issuer is ignorant with respect to 
the consumer's usage of these other cards and can 
therefore not make informed decisions about proper 
marketing strategies targeted towards its existing 
customers . 

SUMMARY OF THE INVENTION 

The present invention solves the problems of 
the prior art systems and methods by performing analysis 
on credit and debit card transactions conducted by its 
customers, regardless of the issuer of the actual cards 
used in the transactions. Complete transaction data is 
obtained by the issuer from a Merchant Acquirer. A 
Merchant Acquirer is an agent for the bank of a merchant. 
The Merchant Acquirer participates in the approval of a 
request for charges by cardholders at the merchant . In 
this role, the Merchant Acquirer obtains all transaction 
data with respect to the merchant's bank and thus is able 
to provide the transaction data to the issuer. 

After the transaction data, including credit 
card numbers, is received by the issuer from the Merchant 
Acquirer, it is "scrubbed" in order to eliminate 
transactions on cards issued by the issuer and to 
eliminate any duplicate non-issuer card numbers. A file 
of "scrubbed" non- issuer credit card numbers is then sent 
to a Credit Bureau for processing. 

The Credit Bureau maintains credit profiles on 
holders of credit/debit cards. Using the scrubbed file 
from the issuer and its own internal credit profiles, the 
Credit Bureau identifies which of the non- issuer card 
numbers in the scrubbed file actually belong to consumers 
who own a card from the issuer. Once this identification 
has been made, the Credit Bureau appends the issuer's 
card number of the consumer to the non- issuer card number 
in the scrubbed file. This update file is then returned 



to the issuer for analysis. In this manner, the issuer 
is able to identify which of its card holders carry other 
credit cards, which cards are used most frequently, where 
the cards are being used and how the consumers uses the 
issuer's card with respect to its other credit cards. 
With this type of information in hand, the issuer can 
develop marketing plans to target its existing customers 
in order to induce the customer to use the issuer's card 
instead of any non- issuer card. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purpose of illustrating the invention, 
there is shown in the drawings a form which is presently 
preferred, it being understood, however, that the 
invention is not limited to the precise arrangement and 
instrumentality shown. 

Figure 1 illustrates the conventional approval 
process when a cardholder requests a charge at a 
merchant ; 

Figure 2 is a high level block diagram 
illustrating the data flow of the processing of the 
present invention; 

Figure 3 depicts processing of transaction data 
performed by the issuer; 

Figure 4 depicts the processing performed by 
the Credit Bureau; and 

Figure 5 illustrates the updating of the 
internal database by the issuer. 

DETAILED DESCRIPTION OF THE INVENTION 

As way of background, Fig. 1 illustrates the 
approval process when a consumer/cardholder 100 has 
requested a charge 105 at a merchant 110. When the 
merchant 100 has received the request for the charge 105, 
it formats the request 105 and forwards a formatted 
request for approval 112 to its bank 125. Typically, 



instead of the bank 125 directly receiving the request 
for approval 112, its agent, a Merchant Acquirer 12 0 
processes the request 112. The Merchant Acquirer 120 
both stores the information constituting the request 112 
and forwards the request 122 to an Association 130 such 
as Visa™ or Mastercard™. The Association 13 0 then 
forwards the request 132 to the institution 135 which 
issued the card to the cardholder 100. The institution 
135 is typically a bank, but is not necessarily always 
so. This institution 135 will be referred to as the 
Issuer 135 Because the Issuer 135 maintains the 
cardholder's account, it is able to determine if the 
request for approval (112, 122, 132) should be granted or 
denied. The decision 134, whether granting or denying 
approval, is forwarded back to the Association 13 0, 
forwarded 124 to the Merchant Acquirer 12 0 and returned 
114 to the merchant 110. The flow 137 between the 
cardholder 100 and the Issuer 135 represents the 
settlement process (i.e., paying the bill). 

As described above, the Merchant Acquirer 12 0 
in its processing of the request 112 retains data 
describing the transaction. In this role, a typical 
Merchant Acquirer 120, on a monthly basis, obtains 
transaction data with respect to millions of transactions 
related to millions of cardholders 100 issued by 
thousands of Issuers 135. Prior to the present 
invention, the Issuer 135 never made use of the 
transaction data acquired the Merchant Acquirer 120. 

Figure 2 illustrates, at a high level, the data 
flow of the present invention. On a regular basis, for 
example monthly, the Issuer 135 requests 205 "raw" 
transaction data from the Merchant Acquirer 12 0. The 
term "raw" in this context means that the transaction 
data has not yet been processed by the Issuer 135. The 
request 205 can also be a standing request (i.e., the 
Merchant Acquirer 12 0 sends the transaction data to the 



Issuer 135 even without having received a specific 
request 205) . In response to the request 205 , the 
Merchant Acquirer 120 forwards 210 "raw" transaction data 
to the Issuer 135. A sample of the types of information 
contained in the "raw" transaction data is described 
below in connection with Table 1. 

Upon receipt of the raw transaction data, the 
Issuer 135 performs a "scrubbing" process on the data as 
more fully described below with respect to Fig. 3. The 
scrubbing process eliminates duplicate transactions and 
stores new transactions related to non-Issuer accounts 
which may be owned by existing Issuer cardholders. As a 
result of the scrubbing process, a file is produced which 
contains transaction records for non- Issuer accounts 
about which the Issuer 135 has no knowledge whatsoever. 
In order to identify if any of the transactions were made 
on non- Issuer cards which belong to an existing customer 
of the Issuer 135, the scrubbed file is transmitted 220 
to a Credit Bureau 200. In order to minimize the 
processing performed by the Credit Bureau 200, the 
scrubbed file can consist of merely a listing of the non- 
Issuer account numbers. 

The Credit Bureau 2 00 maintains credit files 
for each of the existing customers of the Issuer 135. As 
part of these credit files, the Credit Bureau 200 has a 
record of the account numbers of all of the cards carried 
by the customer. The Credit Bureau 200 performs a 
matching operation in which it identifies transactions 
having account numbers which belong to customers of the 
Issuer 135, regardless of whether or not the account is 
an Issuer account. If a match is found, the Credit 
Bureau 200 will append the Issuer's account number to the 
transaction record containing the previously unknown 
account number. The matching process performed by the 
Credit Bureau 200 is described below in connection with 
Fig. 5. 
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Once the Credit Bureau 2 00 has completed its 
matching process, it forwards 225 the file containing 
appended records back to the Issuer 13 5. With the 
appended file in hand, the Issuer 135 is able to update 
its internal database to: 1) link new account numbers to 
existing Issuer account numbers; and 2) update its 
transaction database with the transactions performed on 
the newly identified account numbers. 

Table 1 depicts a sample of the type of 
information (data fields) captured by a Merchant Acquirer 
•3: 35^ with respect to each transaction it processes. 
Typically, the Merchant Acquirer^ik& maintains this 
information in a database with one record per transaction 
with each record containing the fields described in Table 
1. 



TABLE 1 



1 . 


Merchant Name 


2 . 


Merchant Account Number, assigned by 
Merchant Acquirer 


3 . 


Merchant City 


4 . 


Merchant State, Province, Country 


5. 


Merchant Category Code (MCC) 


6. 


Standard Industry Code (SIC) 


7. 


Merchant Zip Code 


8. 


Cardholder Account Number 


9. 


Transaction Amount 


10. 


Transaction Date 


11. 


Card Expiration Date 


12 . 


Cardholder ID 


13 . 


Transaction Code 


14. 


Product Code 



Fields 1 through 7 are each related to the 
merchant 110 involved in the transaction while fields 8 
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through 14 relate more specifically to the cardholder 
100. Field 5, Merchant Category Code (MCC) is an 
industry code which is more refined than the Standard 
Industry Code (SIC) record 6. The cardholder ID, field 
5 12, indicates whether the signature of the cardholder 100 

was verified, a Personal Identification Number (PIN) was 
entered, or whether it was a mail order transaction. The 
transaction code, field 13, indicates the type of 
transaction which occurred (e.g., sale, credit or cash 
10 advance) . The product code, field 14, indicates the type 

of card used (e.g., American Express™, Discover™, or a 
bank card) . Additional information relating to certain 
transactions is also retained by the Merchant Acquirer 
135 but will not be further described as this information 
15 is not essential to the understanding of the present 

m invention. 
y The file of raw transaction data 210 forwarded 

from the Merchant Acquirer 120 to the Issuer 135 can 
contain some or all of the above described transaction 
y 2 0 data. Once the raw transaction data 210 has been 

received by the Issuer 13 5 from the Merchant Acquirer 
2( 120, the Issuer 135 performs a "scrubbing" process on the 

fy raw transaction data as illustrated in Figure 3. 

4? As depicted in Figure 3, the Issuer 135 

y * 25 receives the raw transaction data file 210 from the 

Merchant Acquirer 120. The Issuer 135 then, for each 
transaction record contained in file 210, performs a 
scrubbing process in order to eliminate duplicate and/or 
unnecessary records. The first step 3 00 in the process 
30 is to determine whether or not the transaction relates to 

a card issued by the Issuer 135. If the transaction was 
performed by a cardholder 100 of the Issuer 135, the 
record for the transaction is dropped 302. The 
information relating to this transaction is retained 
35 separately during the conventional process of the Issuer 

135 maintaining the cardholder's account. Accordingly, 
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only transactions which do not belong to the Issuer 135 
should remain. 

In step 305, it is determined if non-issuer 
account numbers appear more than once. If yes, the 
5 duplicate account numbers are eliminated in step 302. 

Once duplicate account numbers have been eliminated, the 
process moves onto step 350 in which it is determined 
whether or not the card account number contained in the 
transaction record already exists in the data warehouse 
10 315. The data warehouse 315 contains, in part, 

information relating to non- Issuer accounts which have 
previously been determined to belong to an Issuer's 
cardholder. The data warehouse 315 further contains all 
of the database files required to perform the processing 
CP 15 of the present invention. Preferably these database 

files are maintained in a relational database in order to 
facilitate relatively quick and simple access to the 
records contained in the database, both for updating the 
v|3 database files and for performing analysis on the data. 

20 Again, in step 350 it is determined whether or not the 

l_l transaction was performed by an Issuer cardholder who has 

[V a non- Issuer account identified in the data warehouse 

^ 315. If the non- Issuer account number is in the data 

a! warehouse 315, the transaction information can be added, 

^ 25 at step 310, to the data warehouse 315. The records 

which survive step 350 reflect card account numbers which 
have not been previously identified as belonging to 
customers of the Issuer 135. 

The process of scrubbing described above is 
30 repeated for every transaction data record received from 

the Merchant Acquirer. Once the file (or a copy thereof) 
containing the transactions records have been scrubbed by 
the above described process, the file is formatted 3 60 
for transmission to the Credit Bureau 200. Typically, 
35 the only information required by a Credit Bureau 2 00 to 

match non- Issuer account numbers to Issuer account 
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numbers is the non- Issuer account number as described in 
the matching process below. 

Fig. 4 depicts the matching process performed 
by the Credit Bureau 200. The formatted file 400 from 
the Issuer 135 is received by the Credit Bureau 200. In 
step 410, an account number from the formatted file 400 
is compared to the Credit Bureau's list of other account 
numbers belonging to customers of the Issuer 135. If the 
account does not belong to any existing customer of the 
Issuer 135, the record for that account number is thrown 
away in step 420. 

If the account number is determined to belong 
to an existing customer of the Issuer 135, then the 
Issuer's account number for the customer is appended to 
the record for the previously unmatched account number. 
Steps 410-43 0 are repeated for every record contained in 
the scrubbed file 400. Once the matching process 410-430 
has been completed, a file 440 containing only the 
appended records is generated and forwarded 450 back to 
the Issuer 135. 

Fig. 5 illustrates the updating process 
performed by the Issuer 13 5 upon receipt of the appended 
file from the Credit Bureau 200. As described above, the 
appended file includes at least records containing the 
account number of the non- Issuer account and the appended 
Issuer account number. For each of the records in the 
appended file, the newly identified non- Issuer account 
number is added to the data warehouse and is linked to 
the existing Issuer account in data warehouse. 
Additionally, the actual transaction information 
associated with the newly identified non- Issuer account 
number can be added to data warehouse 315. 

Once the data warehouse 315 has been updated, 
the Issuer 135 can then perform any variety of analysis 
on this data in order to identify specifically targeted 
marketing opportunities. For example, simple query of 



the data warehouse 315 would identify all of the existing 
customers of the Issuer who have used someone else's 
credit card to rent a car. The Issuer 135 could then 
design a promotion targeted at these existing customers 
which would hopefully induce the customer to use its card 
when renting cars in the future. 

Although the present invention has been 
described in relation to particular embodiments thereof, 
many other variations and modifications and other uses 
will become apparent to those skilled in the art. It is 
preferred, therefore, that the present invention be 
limited not by the specific disclosure herein, but only 
the gist and scope of the disclosure. 



